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ABSTRACT 

The complex and diverse nature of the pay- 
load operations to be performed on the 
Space Station requires a robust and flexible 
planning approach. The planning approach 
for Space Station payload operations must 
support the phased development of the 
Space Station, as well as the geographically 
distributed users of the Space Station. To 
date, the planning approach for manned op- 
erations in space has been one of centralized 
planning to the n-th degree of detail. This 
approach, while valid for short duration 
flights, incurs high operations costs and is 
not conducive to long duration Space Sta- 
tion operations. The Space Station payload 
operations planning concept must reduce op- 
erations costs, accommodate phased station 
development, support distributed users, and 
provide flexibility. One way to meet these 
objectives is to distribute the planning func- 
tions across a hierarchy of payload planning 
organizations based on their particular needs 
and expertise. This paper presents a plan- 
ning concept which satisfies all phases of 
the development of the Space Station 
(manned Shuttle flights, unmanned Station 
operations, and permanent manned opera- 
tions), and the migration from centralized to 
distributed planning functions. Identified in 


this paper are the payload planning functions 
which can be distributed and the process by 
which these functions are performed. 

1. INTRODUCTION 

The key to any successful project, be it a 
complex space mission or a simple family 
picnic, is proper planning and preparation. 
The planning approach used must be tailored 
to meet the specific needs of the problem at 
hand. The Space Station payload operations 
planning problem is considerably different 
from the payload operations planning prob- 
lem associated with current Shuttle mis- 
sions. The characteristics of this problem 
which make it so very different are: large 
numbers of geographically distributed pay- 
load users (e.g., users in the United States, 
Japan, Canada, Europe, etc.), multiple op- 
erations control centers, continuous opera- 
tions, diverse and dynamic payload comple- 
ments, and a desire for operational 
flexibility. With these characteristics in 
mind, it is crucial that a payload operations 
planning concept be developed which meets 
the needs of the payload user community 
and the Space Station program. 

2. PLANNING CONCEPT 

Because of the diverse and dynamic payload 
complement, no one organization will have 
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the knowledge and expertise required to per- 
form all of the detailed planning. Since the 
knowledge and expertise is spread across the 
various organizations and users, it makes 
sense to distribute the planning as well. 
While there are many possible ways of sup- 
porting distributed planning, the hierarchical 
distribution of resources appears to be the 
approach which is best suited for Space Sta- 
tion payload operations planning. An over- 
view of this concept is provided in the fol- 
lowing sections which describe the 
architecture, resource envelopes, and plan- 
ning process. The architecture and resource 
envelopes are discussed first to provide the 
reader with a basis for understanding the 
planning process. Rather than expressing 
this concept using Space Station specific ter- 
minology, the concept is described in gen- 
eral terms which can be applied to other 
planning problems. 

2.1 Architecture 

Figure 1 provides an overview of the archi- 
tecture which supports this approach. This 
architecture consists of various levels of 
planning, where the functions of a particular 
level are performed by one or more organi- 
zations. 


(ULPF), 2) Lower Level Planning Function 
(LLPF), and 3) Intermediate Level Planning 
Function (ILPF). 

The ULPF represents the controlling author- 
ity and is ultimately responsible for the inte- 
grated plan of payload operations. There is 
only one ULPF, although there may be 
many organizations which support its func- 
tions. The LLPF represents the individual 
users of the Space Station. These individuals 
have specific payload operations which need 
to be scheduled, and are in competition with 
one another for the limited resources avail- 
able to support those operations. The ILPF 
represents the organization or organizations 
which serve as the interface between the 
ULPF and the LLPF. In most cases, the 
ILPF represents the sponsoring organization 
or country of the users. In cases where there 
is no ILPF organization, the LLPF interfaces 
directly with the ULPF. There may be multi- 
ple ILPF levels, where one ILPF organiza- 
tion exists to serve the ILPF organizations 
which fall under its authority. Refer to Fig- 
ure 1 for a pictorial representation of this ar- 
chitecture and the relationships between the 
ULPF, ILPF, and LLPF organizations. 



Figure 1. Architecture 


In general, there are three basic levels of 
planning: 1) Upper Level Planning Function 


The basic premise of this concept is that re- 
sources are distributed in a manner which al- 
lows for concurrent planning at each level in 
the architecture. Requests for resources are 
passed from the LLPF upwards through the 
ILPF level(s) to the ULPF. The ULPF, tak- 
ing into account all of the requests for re- 
sources, distributes the available resources 
to the ILPF. Each ILPF then distributes its 
resources to the level below it, either another 
ILPF level or the LLPF. At the LLPF level, 
the users develop plans within their resource 
distributions and pass those plans back up 
through the path to the ULPF. Each level, by 
having a view into all of the requests for re- 
sources at its level, can ensure an equitable 
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distribution of resources to best satisfy the 
needs of its users. The flow of this informa- 
tion from one level to the next is depicted in 
Figure 1. 

2.2 Resource Envelopes 
Resources are distributed to the planning 
levels in the form of resource envelopes. A 
resource request is the time-independent dis- 
tribution of the magnitude of a resource over 
time. In contrast, a resource envelope is the 
time -dependent distribution of the magni- 
tude of a resource over time. The develop- 
ment of envelopes involves assigning a re- 
source request to a specific time period. 
Figure 2 shows an example of a resource en- 
velope. Resource envelopes are created for 
each resource that constrains planning. For 
example, there are envelopes for power, 
data, crew, etc. The resource requirement 
shown in Figure 2 represents a power profile 
required to perform an operation or group of 
operations. The ILPF or LLPF organizations 
may request a resource in excess of the ac- 
tual requirement to allow for the desired op- 
erational flexibility. The resource requests 
are submitted to the appropriate planning 
level for resource envelope development. 


Baa Resource requirement 

HZ] Resource request with flexibility 

E3 Resource envelope with flexibility 



Time (Hours) 


Figure 2. Resource Envelope 


Resource envelopes are developed to satisfy 
resource requests within the resource avail- 


abilities and other constraints. The resource 
envelope defines a profile that is greater 
than or equal to the resource request. Addi- 
tional flexibility may be added to the re- 
source request to simplify the resulting pro- 
file. Once a resource envelope is developed 
and distributed to the appropriate level, ad- 
ditional envelopes can be created at that 
planning level based on the resource avail- 
ability profile provided in its resource enve- 
lope. These envelopes are created in a man- 
ner which ensures that no overbooking of 
the resource occurs. Figure 3 illustrates the 
distribution of resource envelopes. 



2.3 Planning Process 

The process for developing payload opera- 
tions schedules is usually tailored to the en- 
vironment in which the planning is per- 
formed. Problem characteristics, planning 
cycles, unique product requirements, func- 
tional interfaces, and planning software ca- 
pabilities factor into the definition of the 
planning process. The distribution of plan- 
ning responsibilities will also significantly 
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affect the design of the planning process. 
The Space Station payload planning process 
will therefore differ somewhat from the 
processes used for Space Shuttle/Spacelab 
payloads or for unmanned ffee-flyer pay- 
loads, However, there are also similarities. 
The Space Station planning process must 
support manned operations, like Shuttle/ 
Spacelab, as well as continuous operations 
and unmanned periods, like the free-flyers. 

The key to developing a distributed planning 
process is that all planning processes are 
built upon the same fundamental set of plan- 
ning functions: 

• Constraint Definition 

Defines all constraints on scheduling, in- 
cluding the scheduling horizon, ground- 
rules, definition of resources and system 
configurations, resource availability pro- 
files, etc. Resources may represent 
physical objects, such as equipment; sys- 
tems services, such as power; or environ- 
mental conditions, such as microgravity 
or orbital daylight. 

• Requirements Definition 

Defines the requirements of each opera- 
tion to be scheduled. These requirements 
may include resource usage profiles, 
temporal relationships to other opera- 
tions, and performance requirements 
(number of performances of the opera- 
tion and their required distribution over 
time). 

• Scheduling 

Produces conflict-free schedules which 
satisfy the scheduling requirements 
within the defined constraints. 

• Product Generation 

Produces integrated payload plans and 
data which can be used to analyze and/or 
execute the schedule. 

The major difference between a centralized 


planning process and a distributed one is 
who performs each of the functions. 

Typically, the requirements definition func- 
tion is performed by those organizations or 
individuals who have in-depth knowledge of 
the operations to be scheduled, such as the 
users who sponsor the payloads on the 
Space Station. In the planning architecture 
discussed earlier, these organizations and/or 
individuals would belong to the LLPF. In a 
centralized planning environment, the other 
planning functions are performed by a single 
centralized authority, represented in the 
planning architecture by the ULPF. Figure 4 
represents a typical centralized planning 
process. 
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Figure 4. Centralized Planning Process 


In a distributed planning environment, the 
responsibility for performing each of the 
planning functions may be distributed across 
the entire hierarchy of payload planning or- 
ganizations (ULPF, ILPF, LLPF), as dis- 
cussed in the architecture section. The de- 
gree to which the planning functions can be 
distributed depends on many factors, includ- 
ing the abilities and desires of the various 
organizations to actively participate in the 
planning process. 
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Figure 5 depicts a distributed planning proc- 
ess with each of the planning functions fully 
distributed across the various planning lev- 
els (ULPF, ILPF, LLPF). A discussion of 
this process follows. To simplify the discus- 
sion, Figure 5 is shown with exactly one 
ILPF level between the ULPF and LLPF. 
The process can easily be modified to ac- 
commodate an architecture with multiple 
ILPF levels or no ILPF level at all. It will 
also support centralized planning if the 
ULPF organization performs all of the plan- 
ning functions except requirements defini- 
tion, which must be done by the LLPF. 

The Constraint Definition function may be 
distributed if there are particular resources 
or groundrules which are unique to a single 
payload (LLPF) or group of related payloads 
under a common ILPF organization. For ex- 
ample, a group of life science payloads un- 
der a common ILPF might share the use of a 
life science glovebox. Such constraints may 
be defined at the appropriate ILPF or LLPF 


level. Space Station systems services, crew, 
and all other constraints which apply across 
multiple ILPF organizations must be defined 
and controlled by the ULPF. Although con- 
straints may be defined at any level, it is ex- 
tremely important that all organizations are 
planning against a common and consistent 
set of constraints. Visibility into all levels is 
required to ensure that conflicts in constraint 
definition do not occur. For example, the 
creation of three distinct resources with the 
name "Glovebox" by different organizations 
would complicate the schedule integration 
function later in the process. 

As in the centralized process, the Require- 
ments Definition function is primarily per- 
formed by the LLPF. In the centralized proc- 
ess, the LLPF submits detailed scheduling 
requirements which the ULPF can utilize in 
scheduling and product development. In a 
distributed process, however, the LLPF sub- 
mits requests for resources within which it 
can perform its own detailed scheduling. As 



Figure 5. Distributed Planning Process 
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was discussed in the section on resource en- 
velopes, a resource request may represent 
the exact requirements of a specific opera- 
tion, or it may grossly define a set of re- 
sources which accommodates the require- 
ments of one or more operations. A gross 
resource request will provide the LLPF with 
any desired flexibility in the detailed sched- 
uling step of the process. 

Each ILPF collects and assesses the resource 
requests submitted by its associated LLPF 
organizations. Conflicts between LLPF re- 
quests are resolved at this point. Based on its 
objectives and priorities, the ILPF may 
choose to forward any or all of the individ- 
ual LLPF resource requests to the ULPF. 
The ILPF may also choose to merge multi- 
ple LLPF resource requests into larger ILPF 
resource requests. This may provide the 
ILPF with some desired flexibility in the 
scheduling step of the process. 

When all of the ILPF/LLPF resource re- 
quests are submitted, the ULPF is ready to 
begin the Scheduling process. By having 
visibility into all users’ needs (via the re- 
source requests), the scheduling process can 
ensure an equitable distribution of resources 
across the entire payload complement. First, 
the ULPF schedules the integrated set of re- 
source requests against the defined con- 
straints. From this integrated schedule, re- 
source envelopes are then constructed for 
each ILPF. These envelopes may contain re- 
sources in excess of what was requested by 
the ILPF. A key aspect of this concept is that 
the sum of the distributed resource enve- 
lopes created at any level cannot exceed the 
resource availabilities (no overbooking of 
resources allowed). This ensures that the de- 
tailed schedules created at lower levels will 
not produce constraint violations when inte- 
grated together. Note that the ULPF may 
only distribute resource envelopes for those 


resources which are under its control. 

Next, each ILPF follows a similar process to 
divide its resource envelopes into individual 
LLPF resource envelopes. Any resources 
under the control of the ILPF may be distrib- 
uted at this time. 

Detailed scheduling of specific operations is 
then performed by the LLPF within the re- 
source envelopes assigned by the ILPF. 
Prior to scheduling, the LLPF completes the 
Requirements Definition process for its op- 
erations by defining/updating the detailed 
scheduling requirements. 

The last step in the Scheduling process is the 
integration of the independently developed 
detailed schedules. Integration is performed 
in an upwards fashion through the ILPF to 
the ULPF. Each planning level verifies that 
the detailed schedules it integrates are com- 
patible with the appropriate resource enve- 
lopes, As part of the integration function, the 
ULPF may perform any additional planning 
tasks required to finalize the integrated 
schedule of payload operations. 

The Product Generation function may also 
be distributed to a certain extent. Some addi- 
tional information, not required for schedul- 
ing, must be associated with the payload 
schedule in order to generate the products 
which are used by the onboard crew, on- 
board software, and ground controllers to 
execute the schedule. Examples of these 
product inputs include identification of the 
detailed procedures to be executed for each 
scheduled operation, and associated notes. 
Since the LLPF has the most intimate 
knowledge of the payload operations and 
procedures, it builds the product inputs, 
which are then integrated by the ILPF and 
ULPF for inclusion in the final products. 
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3. ANALYSIS AND EVALUATION 

As with any complex concept or process, 
there are a number of strengths and weak- 
nesses associated with the distributed plan- 
ning concept described in this paper. A dis- 
cussion of the known advantages and 
disadvantages follows. 

3.1 Advantages 

The distributed planning concept provides a 
number of advantages which make it par- 
ticularly attractive as a solution to the Space 
Station payload operations planning prob- 
lem. Following is a brief summary of these 
advantages: 

• Reduces the operations costs of the 
ULPF organization through the in- 
creased participation of the ILPF and 
LLPF organizations. 

• Provides operational flexibility at the ap- 
propriate level of fidelity through the use 
of resource requests and resource enve- 
lopes. This flexibility results in a plan 
which is better able to accommodate 
changes during plan execution. 

• Places responsibility for planning at the 
level where the knowledge and expertise 
exists. The end users (LLPF) are active 
participants in the process and are not 
simply viewed as data providers. 

• Results in the production of conflict-free 
plans through the use of resource enve- 
lopes which do not allow for the over- 
booking of resources. 

• Supports the transition from centralized 
to distributed planning, as well as a mix- 
ture of both centralized and distributed 
concepts. The planning process remains 
fairly stable regardless of the number of 
organizations performing the various 
planning functions. 

• Ensures equitable distribution of re- 
sources among the payloads through 


visibility into the integrated set of re- 
source requests. 

3.2 Disadvantages 

The distributed planning concept also has a 
number of disadvantages associated with it. 
Many of these disadvantages are a direct re- 
sult of the distribution of planning functions 
and would probably manifest themselves in 
other distributed planning concepts. Follow- 
ing is a brief summary of these disadvan- 
tages: 

• Increases operations costs to the ILPF 
and LLPF organizations due to then- 
more active role in the planning process. 

• Results in less efficiency in the planned 
utilization of resources. The flexibility 
built into the resource requests and re- 
source envelopes results in the schedul- 
ing of resources which may not actually 
be utilized. 

• Results in longer planning cycles due to 
the active involvement of all levels in 
the planning process. Sufficient time 
must be provided to allow each level to 
perform its required functions, as well as 
to account for the transfer of information 
from one level to the next. 

• Requires a significant amount of coordi- 
nation to define the planning constraints. 
The success of this concept depends on 
all of the various organizations using a 
well defined and consistent set of plan- 
ning constraints. 

• Results in numerous and complex inter- 
faces to support the distribution of the 
planning functions. Organizations in- 
volved in the process will be geographi- 
cally distributed and will be working in 
facilities which may or may not be simi- 
larly equipped. 

• Requires a rigorous configuration man- 
agement process to ensure that all or- 
ganizations are using the most current 
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data and that changes to the data are only 
made by authorized organizations. 

4. CONCLUSIONS 

The complex and diverse nature of the pay- 
load operations to be performed on the 
Space Station will require a change in the 
current payload operations planning philoso- 
phy. The unique characteristics of the Space 
Station payload operations planning problem 
drive the need for a distributed payload op- 
erations planning concept. 

The key to a successful payload operations 
planning concept is to develop an approach 
which will meet the needs of the payload 
user community and the Space Station pro- 
gram. The authors believe the distributed 
planning concept presented in this paper 
provides a robust and flexible planning ap- 
proach which will support the phased devel- 
opment of the Space Station, accommodate 
a large number of geographically distributed 
users, accommodate diverse and dynamic 
payload complements, as well as provide for 
operational flexibility. There are significant 


benefits to be gained with this concept if the 
Space Station program is willing to accept 
the disadvantages. The authors feel this is a 
viable concept which is being actively pur- 
sued for implementation. This concept will 
need to be revisited to accommodate 
changes as the Space Station program 
evolves. Also, it is acknowledged that cer- 
tain functions associated with this concept 
will require further study and development. 
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